home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98a.txt / 000064_icon-group-sender _Thu Feb 26 13:58:29 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  4KB
  1. Return-Path: <icon-group-sender>
  2. Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
  3.     by baskerville.CS.Arizona.EDU (8.8.7/8.8.7) with SMTP id NAA08833
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Thu, 26 Feb 1998 13:58:28 -0700 (MST)
  5. Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA32133; Thu, 26 Feb 1998 13:58:28 -0700
  7. Date: Thu, 26 Feb 1998 16:06:02 GMT
  8. Message-Id: <199802261606.QAA12542@gairsay.aiai.ed.ac.uk>
  9. From: Jeff Dalton <jeff@aiai.ed.ac.uk>
  10. Subject: Re: Translation into C
  11. To: icon-group@optima.CS.Arizona.EDU
  12. In-Reply-To: gep2@computek.net's message of Wed, 25 Feb 1998 13:30:10 -0600
  13. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  14. Status: RO
  15. Content-Length: 3320
  16.  
  17. Gordon Peterson wrote:
  18.  
  19. > > Mark Evans suggested that the reason one might want an Icon to C
  20. > translator is that the resulting program will execute faster because it
  21. > doesn't need to be interpreted.  But I wonder how much difference that
  22. > would really make.  If the C program spends most of its time calling
  23. > library routines, then I wouldn't expect much difference at all.
  24. > 
  25. > Right.
  26. > 
  27. > > Does anyone have statistics that might answer this question?
  28. > 
  29. > I think that statistics for different implementations will vary all over the 
  30. > place... I'd comment though that generally the overhead of an interpreter is 
  31. > less (and the advantages are more) for higher-level languages than for 
  32. > lower-level ones, for exactly the reason you yourself suggested
  33. > above.
  34.  
  35. The experience with Lisp has been that compilation to "native code"
  36. (even via compilation to C) makes a big difference.  (Probably a
  37. factor of 10 to 30 over list-structure interpreters), though I haven't
  38. seen actual statistics for a long time.)  I normally run any
  39. substantial Lisp program compiled if I can, and I have seen it make
  40. a factor of 30 difference.  (N.B. 30 times faster, _not_ 30 percent.)
  41.  
  42. Prolog, however, has often been implemented by compilation to byte
  43. codes (or similar) with a heavily optimized and cleverly written
  44. interpreter for the byte codes.  My impression was that this worked
  45. fairly well, though again I don't have actual numbes to hand.
  46.  
  47. A more or less straight interpreter for Porlog (cprolog) was 
  48. suprisingly fast for an interpreter, but still sunstantially
  49. slower than the byte-code-compiled systems.
  50.  
  51. (Asking in Comp.lang.lisp, Comp.lang.scheme, and Comp.lang.prolog
  52. might be a good idea.)
  53.  
  54. When Lisp (and I include Scheme in Lisp) is compiled to byte codes,
  55. the result can be ok, but so far I haven't found it a completely
  56. satisfactory alternative to full compilation.
  57.  
  58. An example of a commonly-used Lisp compiled to byte codes is the one
  59. in GNU emacs.  It seems to work fairly well (obviously, opinions
  60. differ about almost everything when it comes to Emacs), but the sorts
  61. of things people do in Emacs probably have the Lisp spending a greater
  62. proportion of time in "library routines" than is typical for Lisp
  63. programs.
  64.  
  65. My suspicion is that it may well be a win to compile Icon to native
  66. code via C, but how much of a win will depend on how much the compiler
  67. manages to compile in-line and on what the alternative implementations
  68. are.  A simple compile-via-C compiler that didn't compile much in-line
  69. might not produce much faster results than a very good compiler to
  70. byte codes plus a very good interpreter for the byte codes.
  71.  
  72. The design of the byte-code instruction set also matters.  There
  73. was a revolution in Prolog implementation that came with the so-called
  74. Warren Abstract Machine (WAM), and earlier, more stack-machine-like,
  75. instruction sets could not compete.
  76.  
  77. (By "byte codes", etc, I really mean instructions for some virtual
  78. machine.  These are often byte-codes, but they can be longer or vary
  79. in other ways.)
  80.  
  81. (For some reason the Java VM is a stack machine, despite the
  82. involvement of people who knew what had happened in the Prolog
  83. world.  But perhaps they are not expecting to get Java speed
  84. via VM efficiency, relying instead, perhaps, on various sorts
  85. of more complete compilation.)
  86.  
  87. -- jeff
  88.